Batch processing techniques are utilized to efficiently process multiple documents in a consistent manner. In the health care industry, for example, claims submitted by various medical providers to various payers, such as insurance companies or the like, may be submitted and processed in batches. Similarly, orders, ticket requests or the like may be submitted in batch form to a prospective vendor.
While batch processing may be utilized in a wide variety of circumstances, batch processing provides particular efficiency in instances in which the batches may contain many documents, such as hundreds or thousands of documents. In order to efficiently process the plurality of documents included within a batch, standardized procedures are generally adopted that govern the manner in which the documents will be processed. As such, the documents can generally be processed in batch form in an automated manner.
In some instances, the procedures governing the manner in which batches of documents are to be processed specify that a batch of documents should be rejected if any one of the documents included in the batch does not comply with certain predefined specifications, such as the specifications defining the syntax according to which the documents are to be submitted. As such, a batch containing thousands of documents could be rejected if any one of the documents included in the batch had a syntactical error. Since the entire batch is rejected, numerous documents included in the batch that complies with the predetermined specifications, such as by having the predefined syntax, are rejected along with the non-compliant documents. As will be apparent, the rejection of the entire batch of documents slows down the processing of the documents since the sender must address any syntactical or other errors and then resubmit the entire batch.
By way of example, the submittal of many types of documents by health care providers to various payers is governed by the Health Insurance Portability and Accountability Act (HIPAA) that mandates batch processing of the documents as described below. HIPAA addresses a variety of topics including limitations on exclusions for pre-existing conditions, availability of health insurance coverage for small employers, strengthening of federal health care fraud and abuse laws and administrative simplification and privacy. With respect to administrative simplification, HIPAA was designed to improve the efficiency of the health care system by standardizing the electronic exchange of data and protecting the security and privacy of the health information exchanged thereby.
The administrative simplification component of HIPAA has five (5) elements, each with supporting regulations issued by the U.S. Department of Health and Human Services (HHS). The five elements are: (i) code sets that require the use of standard codes in completing electronic health care transactions, (ii) privacy that restricts the use and disclosure of health information by providers, health plans, health care clearinghouses and their respective business associates, (iii) security that requires reasonable and appropriate administrative, technical and physical safeguards for electronic protected health information, (iv) unique identifiers that require the use of standard unique identifiers for employers, providers, payers and individuals and (v) electronic transactions that require the use of standard electronic formats for eight (8) different health care transactions.
The regulations governing the electronic transactions conducted pursuant to HIPAA require payers and providers to utilize standard formats and content for each of the following transactions:
Transaction TypeHIPAA StandardEligibility Inquiry and ResponseASC ANSI X12N 270/271Claim Status Inquiry and ResponseASC ANSI X12N 276/277Referral/Precertification RequestASC ANSI X12N 278and ResponseHealth Plan Premium PaymentASC ANSI X12N 820Benefit Enrollment and MaintenanceASC ANSI X12N 834Claim Payment and RemittanceASC ANSI X12N 835Professional, Institutional, orASC ANSI X12N 837Dental Health Care Claim/EncounterProfessional, Institutional, orDentalPharmacy ClaimNCPDP version 5.1
As used in the foregoing table, ASC ANSI represents the Accredited Standards Committee of the American National Standards Institute. ASC ANSI X12, also known merely as X12, is considered to be the primary standard for North American trading using electronic data interchange (EDI). As the above table indicates, the transaction regulations have developed several standards premised upon the X12 standard. For the various types of transactions that have associated standards, the electronic transactions must be conducted according to those standards. While providers may conduct these transactions either electronically or on paper, providers that conduct the transactions electronically must utilize the standard format. Moreover, payers are required to accept the electronic transactions if the electronic transactions are submitted in standard form.
Since not all payers are capable of communicating with providers in accordance with the HIPAA regulations, payers may contract with health care clearinghouses 12 to sit between the providers 10 and the payer 14 so as to translate the messages communicated therebetween, as shown in FIG. 1. In this regard, the providers who transmit electronic transactions according to the HIPAA regulations may direct the electronic transactions to the clearinghouse. The clearinghouse receives the electronic transactions and translates those transactions to a proprietary format utilized by the payer. The translated message is then communicated to the payer. Conversely, messages from the payer intended for the provider are received by the clearinghouse and translated from the proprietary format utilized by the payer to the standard format defined by the HIPAA regulations. The clearinghouse can then provide the translated message to the provider. As also shown in FIG. 1, the clearinghouse need not always receive the electronic transactions directly from the providers, but may, instead, communicate with another clearinghouse or with a billing service, repricing company, switch or other intermediate entity 16 which, in turn, communicates with the provider.
The X12 standard defines the message structure which, in turn, defines the order in which documents and other data are to be presented. In this regard, documents are transmitted pursuant to the X12 standard in packages termed interchanges as shown in FIG. 2. As described below, the documents are organized into various envelopes that provide information relating to the enclosed documents and facilitate proper processing of the documents. As will be known to those skilled in the art and as shown in FIG. 2, each envelope generally includes a header and a corresponding trailer or footer with the header preceding the enclosed documents and the trailer or footer following the enclosed documents.
The outermost envelope is the ISA/IEA envelope 20, also known as the interchange envelope, that isolates one group of transmitted documents from another group. Several dissimilar types of business documents can be included in an interchange envelope with each different type of business document separated from other types of business documents as described below. Among other parameters, each interchange envelope includes a control number that serves to identify the interchange envelope. This control number is sequential between a provider and a payer and can be utilized for statistical control, audit control and to provide error recovery information. As several different versions of the same interchange standard may exist, the interchange envelope also generally defines the particular version of the interchange envelope.
Within the interchange envelope 20 are one or more GS/GE envelopes 22, also known as functional group envelopes. Each GS/GE envelope isolates one group of documents from another. As such, while several dissimilar types of documents can be included within one interchange envelope, each different type of document is contained in a respective GS/GE envelope. Thus, medical claims from several different providers for several different subscribers may be included in one GS/GE envelope, while a functional acknowledgement is included in another GS/GE envelope within the same interchange envelope. Among other parameters, the header and/or footer of the GS/GE envelope identifies the type of documents included within the envelope as well as the version, data dictionary and segment directory that may be utilized to interpret the documents included therein.
Within the GS/GE envelope 22 are one or more ST/SE envelopes 24, also known as transaction set envelopes, that serve to isolate one batch of documents from another. In this regard, several batches of the same type of document can be contained within the same GS/GE envelope with each batch of documents being contained in its own ST/SE envelope. Within a single GS/GE envelope, for example, one ST/SE envelope may include medical claims from one provider while another ST/SE envelope may include medical claims from another provider. The header and/or footer or trailer of the ST/SE envelope may include a control number for audit trail purposes, as well as other parameters.
As a more particular example, the hierarchal structure defined by ASC ANSI X12N 837 for professional, institutional, or dental health care documents is shown in FIG. 3. In this example, a single GS/GE envelope 22 is included within a single ISA/IEA envelope 20, thereby indicating that the file includes one group of similar documents. Within the GS/GE envelope are two ST/SE envelopes 24. Within each ST/SE envelope 26 is a batch 26 of documents submitted by a respective provider such that all of the documents included in a particular ST/SE envelope originate from the same provider. The batch of documents submitted by a respective provider may include documents relating to one or more subscribers or patients. In the first batch included in the first ST/SE envelope, for example, a first provider designated by HL*20 has submitted two documents for a first subscriber designated HL*22 with claims CLM*1 and CLM*2 and a single document for a second subscriber designated CLM*1. By way of another example, the second batch depicted in FIG. 3 was submitted by a second provider designated as HL*20 and includes a single document for a first subscriber denoted HL*22 with claim CLM*1 and two documents for a second subscriber designated HL*22 with claims CLM*1 and CLM*2.
Upon submittal of a batch of documents, the payer 14, or a clearinghouse 12 if the payer is not capable of receiving and properly processing messages formatted according to the X12 standard, reviews the batch of documents to see if the claims are compliant with the predefined specifications set forth by the HIPAA regulations. As described above, if any one or more of the documents included in the batch are non-compliant, such as by having an improper syntax, the entire batch is rejected. In this regard, a rejected batch is returned by the payer, or its clearinghouse, to the provider such that the provider 10 can cure any error, such as any syntactical error, and then resubmit the batch at some point in the future. With reference to the example provided in FIG. 3, an error in the documents submitted for the second subscriber in the first batch would cause the entire first batch to be rejected even though both documents submitted for the first subscriber in that same batch complied with the specifications.
As such, it would be desirable to provide an improved technique for increasing the speed and efficiency with which suitably formatted documents are processed. In this regard, it would be desirable for processing batches of documents in order to permit documents that comply with the predefined specifications to be paid or otherwise further processed in a timely manner without being delayed pending resolution of errors identified in one or more of the other documents.